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This Invention describes an error-recoverv method for streaming Rne-Granularitv-Scalabllltv 
coded video over tiie Internet. In tiiis metiiod. effor-recoven/ data, such as duplicated packets or 
redundant oackete generated Jos/ F EC (Fonward-Emor-Correction^ algorithms are seoaratelv stored 
in an error-protection track, afona with original video tracks. When receiving error happens, the 
recovery is achieved bv the receiver's subscription to the streaming channel that Is assigned to 
deliver this orotection track. 

PRESENT STATE OF THE ART 

Briefly describe the closest already-known technology that relates to the invention. This woukl 
include, for example, already existing producte, methods or compositions which are known to you 
personeUIy or through descriptions in publications. 

Currentlv. there are two types methods used in practice for error-recoverv: retransmission and 
fonward-e rror-correction tor simolv FECV With retransmission, when errors occur at the receiver, 
such as a packet gets iost in the network, the receiver needs to first detect this loss event and 
then send a retransmission reouest back to source for recovery. With FEC. the source normally 
evenly embeds redu ndant packets into tiie original packet flows, hoping that when enors happen 
with original packets, some redundant packets can still be able to successfully make to the 
receiver, so the lost rackets can be recovered from these redundant packets. 

The advantage gf retransmission is high bandwidth utilization. The disadvantage Is retransmission 
involves ouite a del ay of recoven/. at least a round-trio time, for example. Therefore, the 
retransmission method has limited usage, especially not feasible for interactive multimedia 
applications with real-time constraint such as teleconferencing. 



The FEC method is the opposite of the retransmission. FEC can guicklv do error-recoverv. but 
involves ouite an overiiead of bandwidth consumption. FEC Is nonmallv used when wireless linte 
are parts of the communications channels. 



ADVANCEMENT IN STATE OF THE ART 

Briefly describe the unique advancement achieved by the invention. This may be done, for 
example, by describing a problem with the prior art that is solved or specific objects that are 
kchieved by the invention. 

in the past, there is a distinct line between these two methods. An application has to weigh to 
choose either retransmission or FEC. However, the Internet is heterogeneous and evolving. 
Same applications could operate In completely different network environments when started by 
different users widely spread across the Intemet Also, the network conditions are hard to pr&dici 
causing difficulty for choosing the right error-recovery methods once forever for all the 
applications. 

An Ideal solution for error-recovery would be that retransmission and FEC could be somehow 
combined together. An application has the freedom to dynamically choose either of them or 
combine In real-time according to its perceived network conditions. 

Recently, we have seen a report that presents an error protection method that separate 
protection streams from media streams, and performs join/leave to achieve protection. This 
method is commonly referred to as adaptive FEC. This method has the following limitations: 

• It uses IGMP (Internet Group Management Protocol) to signal the join/leave action, which 
may introduce a very long latency in the signaling process that eventually defeat the 
protection purpose, such as retransmission. 

• It emphases on the FEC coding algorithm but lacks an architecture and protocols to carry 
out the goals of adaptive FEC. 



Our Invention describes a method that goes beyond just the basic idea of adaptive FEC. It 
presents a realistic architecture and specifies the protocols that are needed for carrying out 
protection. With bur method, applications are able to switch between protection styles 
dynamically. 

(ADD UNES AS NECESSARY, IF COMPLETING ON COMPUTER, OR ATTACH ADOmONAL PAGES) 

WHAT IS THE BEST WAY YOU KNOW OF TO IMPLEMENT THE INVENTION? 

Briefly describe the invention and liow it achieves the advancement described in paragraph 7. 

This en*or-recovery method can be seamlessly fitted into the overall FGS streaming architecture 
that was described by a previous disclosure (No. 702116). In this streaming architecture, FGS 
coded video are fomnatted into multiple tracks, and streamed to the clients using multiple networic 
conneclior>s (or channels, in another words). One of these channels is reserved for the base layer 
(or track), while the rest for the enhancement layer (which is stored in multiple tracks). 

Our error-recovery method can be implemented as the following. 

■ Add a separate protection track or tracks along witti the original video tracte. The data of this 
track could simply be the duplications of tlie l-Frames of the base layer, or generated by a 
common FEC algorithm. The protection level is determined by the data stored in this protection 
track. In order for the sen/er to use this protection track, a corresponding hinting track is also 
needed for this protection track. 



mm* 



A signaUrig protdHP^or the subscription of the protecfrcj^^lll/^ifytdg^^ jJafc^^^done 
by using RTSP. The subscription to this protection channel could be permanent, behaving like 
the ordinary FEC method, or temporsuy, depending on perceived network loss concUtions. or 
even to the extreme, one decodable unit at a time to mimic the retransmission method. 
■ The receiver needs to monitor its receiving quality and actively triggeiB the protection channel 
when it deems necessary. 

This method is also schematically shown in the following Figure. 



Server 



IP Network 



Client 




' . ■: ■■; i . . . ; - • > •. : ' ; >- • -V.- 



Channel Subscribe 




UDP^ 























Protection Channels 



Iprol 

— IT 



In this figure, one or more RTP channeis will be used for protection. Protection channel 
subscriptions will be done using RTSP. and initiated by the client. 

The advantage of this method may reflect In the following. 

■ Fully take advantage of the QuickTime file fomiat, and the popular DanA^in Streaming server 
architecture. 

■ Protection data are separated from protected data. Change the protection data can change 
the protection level, but the protection method remains the same. 

■ With this method, applications can dynamically choose either retransmission-like protection 
or FEC-like protection, or in the middle, therefore, gaining better protection perfonnance. 

■ Using RTSP instead of IGMP can achieve faster protection and provide more flexibility to 
applications. 

■ This method works well for both unicast and multicast. 

(ADD UNE8 A8 NECESSARY, IF COMPLETING ON COMPUTER. OR ATTACH ADDITIONAL PAGES) 



LEASE NOTE : IF WE DECIDE TO FILE AN APPUCATiON ON THIS INVENTION, THE 
ATTORNEY WRITING THE APPLICATION WILL NEED THIS INFORMATION FROM YOU 
IN AS MUCH DETAIL AS POSSIBLE IN ORDER TO COMPLETE THE APPLICATION. 



DISCLOSURE OUTSIDE OF PHILIPS 

If the invention has been or will be disclosed publicly or to anyone other tiian a Philips* employee. 
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Abstract 



In this contribution we present a streaming architecture framework for streaming scalable coded video over 
IP networics. Hds architecture uses multiple channels (or more precisely, multiple IP connections for 
unicast and multicast-group channels for multicast) to deliver scalable coded video. This framework 
includes hinting scheme for scalable video, a protection strategy for achieving unequal protection and 
protection on demand, and extensions to standard Internet streaming protocols (RTSP, SDP) for conducting 
channel controls. The concept of this proposed framework has been verified by a prototyping 
in^lementation. 

1. Introduction 

With the rapid development of broadband Internet technologies, video streaming is envisioned to become 
the dominant Internet application in the near friture. Similarly, the felling cost of WLAN products has also 
led to fheir increased use in consumer homes, and although currently most WLANs are predominantly used 
for data transfer, the higher bandwidth provided by new WLANs technologies such as IEEE 802.11a and 
IEEE 802.1 Ig will ultimately lead to their increasing use for video transmission. Furthermore, friture 
wireless video applications will have to work over an open, layered, Internet-style netwoik with a wired 
backbone and wireless extensions. Therefore, common protocols will have to be used for the transmission 
across both the wired and wireless portions of die network. These protocols will most likely be future 
extensions of the existing protocols that are based on ttie Internet Protocol (IP). 

Consequently, due to the inherent resource sharing nature of the Internet and wireless networks, multimedia 
communications of the future will mainly use variable bandwidth channels. Hence, if streaming of video 
content is performed over this type of networks, the instantaneous data rate must frequently be tailored to 
fit the available resources. This can be achieved in a very flexible way by the approach of scalable coding. 
Scalable video-coding schemes are able to provide a sinqile and flexible framework for transmission over 
heterogeneous networks, since: 

• They enable a streaimng server to perform minimal real-time processmg and rate control when 
outputting a very large number of simultaneous unicast (on-demand) streams (unlike transcoding or 
simulcast approaches). 
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• They are highly adaptable to unpredictable bandwidth variations due to heterogeneous access* 
technologies of the receivers (e.g. analog modeni, cable mode, xDSL, etc.) or due to dynamic changes 
in network conditions (e.g. congestion events). 

• They enable low-con^lexity decoding and low-memory requirements to provide common receivers 
(e.g. set-top-boxes and digital televisions), in addition to powerful conq)uters, the opportunity to stream 
and decode any desired video content 

• They are able to support both multicast and unicast applications. This, in general, eliminates die need 
for coding content m different formats to serve different types of applications. Moreover, for multicast 
applications, the scalable coded streams require less bandwidth for transmission. 

• They are resilient to packet and bit-error losses, which are quite common over the Internet and wireless 
networks. 

Exan^)les of scalable codiflg schemes are the MPEG-4 Fine Granularity Scalability (FGS), Advanced FGS, 
Data-Partitioning, MPEG-4 Spatial and Tenq)oral Scalabilities, emerging Motion-Compensated Wavelet 
Solutions etc. However, in order to provide the required adaptation to bandwidth variations, device 
characteristics and user requirements, the scalable video coding needs to be transmitted using an 
appropriate streaming architecture. 

The MPEG-4 Systems Group has developed and standardized the streaming strategy for non-scalable coded 
video over IP networks. However, a novel streaming architecture is required for the transmission of 
scalable video formats standardized by MPEG that is able to take advantage of their flexibility in order to 
efficiently adapt to channel conditions, complexity constraints and user preferences. 

In this contribution, we describe such a fl^ible streaming architecture framework that includes a pre- 
processii^ method (hinting) for flexible scalable video packetization, an efficient protection strategy and 
the necessary streaming control protocols. Particularly, we propose a multi-track-hinting concept for 
scalable video, and extend the functions of standard Intemet streaming protocols (RTSP, SDP) to enable 
flexible adaptation. One principle we have followed in the process of defining this framework is that the 
scalable vi^ieo streaming system architecture should be compatible with that of the non-scalable streaming 
system defined by MPEG, such that a general purpose MPEG-4 streaming server can deliver both types of 
video. 

2. Multi-track Hinting 

Multi-track hinting is a method proposed in diis contribution for structuring layered video mto a file format 
that is backwards compatible with the MPEG-4 media file format standard, therefore making it possible to 
use a general-puipose MPEG-4 streammg server to stream layered video. Using this method to prepare 
layered video for streaming will enable the server (without major modifications) to automatically use 
multiple channels to deliver the scalable video over IP networks. The channels can be controlled using the 
mechanisms described in the next section. 

The MPEG-4 standar d ization body has developed a standard media file format Cu^^) [1] diat contains 
timed media information for multimedia presentation either locally or remotely (such as streaming). This 
format is deliberately designed with high flexibility and extensibility in order to facilitate interchange, 
management, editing, and presentation of the media. . 

The standard file format has an inherent hierarchical structure. The basic building blodcs used m the 
construction of mp4 files are called Boxes, A box is a specially designed data structure diat contains a 
certain type of media data. Each box has a type name, reflecting the type of data it contained. Also, a box 
can contain other boxes, and so on so forth to form a hierarchical stmcture. 

The geneml structure of a mp4 file format for streammg is illustrated in Figure 1 . Normally, an Tnp4 file 
starts with a root box called moov. The moov box further contams other boxes, such as, boxes for storing 
elementary bit steams, boxes for storing synchronization information (or called movie tracks), and boxes 
for. storing hmts used by streaming server to generate packets out of tiie elementary bit streams (these boxes 
are called hint tracks). On the highest level of abstraction, a mp4 file can be view as a structure containing 





elementary bit streams generated by encoders, movie tracks to guide player for local playback; and hint 
tracks for streaming the media over packet-based networks. 



moov 




Figure 1: file fonnat 

The arrows in Figure 1 indicate diat the movie tracks are related to elementary streams, and die hint tracks 
to ttie movie tracks. The movie tracks contain information (timing and data pointers) that a player will use 
to extract the corresponding media data for presentation at the designated time. Hint tracks contain 
information (such as timing, data pointers and data for packet headers) ^at a server will use to generate 
packets out of elementary bit streams. Hint tracks are created by a tool/processor called "hinter^' based on 
movie tracks. 

When mp4 file is used in a streaming application, normally the server will establish a number of RTF 
connections equal to the number of hint tracks that are contained in the file. There is a one-to-one 
relationship between an RTF connection and a hint track. Each RTF connection will be assigned with a hint 
track, and is responsible for delivering packets generated from that track. 

However, the mp4 file format described above does not explicitly address the requirement of layered video 
streaming. In layered video coding, con^ressed video is structured into multiple layers. These layers can be 
added up progressively to iniprove video quality. To take advantage of the scalability provided with layered 
coding, normally multiple RTF connections will be used for layered video streaming, and the totally 
number of die connections will be adapted to the network conditions. 

Layered video coding normally generates one elementary bitstream that can be divided in sub-layers having 
different priorities/importance. If we simply apply the generic mp4 file format to the layered video 
elementary streams - in which for each elem^tary stream the authoring tool generates a movie track and 
then further generates a hint track - we will end up widi a scheme that can only use one RTF connections to 
stream the layered video. Obviously, scalable coding based on this inflexible streammg strategy does not 
allow for the desired adaptation to channel characteristics, conq>lexity etc. 

In order to use a general-purpose streaming server designed to stream generic n^ files for efilcient 
layered video streaming, and at the same time to be able to set up multiple KTP connections for streaming 
corresponding to the various iniportance sub-layers, we propose a hinting method that can generate 
nuiitqple hint tracks out of a single movie tracks. This method can generate files that still comply with the 
rap4 file format When a single movie track is hinted using multiple hinting tracks, the elementary stream 
pointed by the movie track will be delivered over the network by multiple RTF connections, thereby 
providing the streaming system the flexibility to adapt to network conditions by adjusting the transmitted 
number of scalable layera. 



* 



The application of the multi-track hinting concept is beyond the layered coding case. For exan9>le, this 
hinting method can be successfully applied to a video stream to associate different types of video frames (I- 
> B-fiames) to different hint tracks. In this way, the tenqmial video scalability is easily achieved by the 
streaming system. 



The multi-tcack hinting can also be viewed as an extension to the generic xcsgA file format 

The basic idea of multi-track hinting is illustrated in Figure 2. As shown in Figure 2, multiple hint tracks 
are generated for a single movie track, therefore multiple RTP connections will be used by tiie server to 
deliver the elementary stream pointed by this movie track. The multi-to-one relationship between hint track 
and mtovie track breaks the original one-to-one relationship employed for hinting non-scalable streams, 
thereby providing the flexibility necessary for scalable video transmission. 



moov 




Figure 2: Proposed multi-track hinting file format 
Using this multi-track hinting method, the elementary stream is only virtually divided into multiple sub- 
streams, therefore, the physically unchanged elementary stream stays the same and can be played locally as 
before. 



For illustration, we show a pseudo code that describes tiie algorithm for MPEG-4 FGS multi-track hinting 
. in Figure 3. In Figure 3, tfie function max_channel_alIocation(i) will determine the bit rate that will be 
allocated to the /th RTP comiection associated with the i\h hinting track. Therefore, the bit rates of tiie 
streaming chaimels are pre-determined at the hinting stage. 





while ((5ainple_size=get_next_fgs_sample0) > 0) { //loop through all samples 
remaining = san^)lejsize; 
offeet = 0; 

for (i = 0, i < max^hintjtracknum, i++) { //loop through all hinting tracks 
ifl( remainiiig > 0) { 

channeljremainning « lemaiiiing > max_channel_allocation(i) ? 

maxjchamiel_allocation(i) : remaining; 
remaining = remaining > channel_remaining ? 

remaining - channel_remaining : 0; 
while (chamieWemaining > 0) { //generate packets 

if ( channel_remaining <« maxj?acket_payload_size) { 
packet_lengtfa = channeljemaining; 

} else { 

packet_length = niax_j)acket_payloadLsize; 

} 



) 



} 



} 



add_packet_to_hmt_trackj;i](offset); 
of&et packet Jengtl^ 
channeljremaining -= padcet_lengtfa^ 



Figure 3: Pseudo code of proposed FGS multi-track hinting algorithm 

It is possible to develop algorithms for packetization and rate-allocation optimizations when specific 
network conditions and codec characteristics are taken into account These algorithms are application 
specific, and will not be further discussed in this contribution. 

However, it is worth pointmg out that, for a single elementary bit-stream, there could be more than one 
layering schemes, each reflecting a packetization strategy targeted to a specific network condition. In multi- 
track hinting, each of these layer schemes can generate a set of hinting tracks. All hinting tracks associated 
with different layering schemes can be stored in the same file, and made know to users via SDP channel 
profiling mechanism which is discussed in next section, so that users can have options to choose among 
different layering schemes when join a streaming session. 

3. SDP Extension 

The SDP (Session Desmption Protocol) is generally used by a streaming server to describe a streaming 
session to a client In the case of layered video streaming, a few session features that are unique to layered 
video streaming that have not been expected by the original design of the SDP specified in RFC 2327. 
These features are: 

• The video is not just a single stream, but rather contains nullt^>le layer streams transnnitted over 
different IP connections (or channels) with different priorities. 

• The server could recommend different possible channel combinations (referred to as channel profiling) 
to a chent based on network conditions or client capabilities, or offer multq;>le channel profiling 
options for clients to choose. For example, some clients may prefer low firame rates but high quality 
images, while others may prefer the opposite. Hiese different preferences can be satisfied using the 
channel profiling feature. 



• Di£ferent layers could be protected independently by protection tracks (see detail discussion in Section: 
Qn-Demand Protection). A server needs a mechanism to signal to ihe clients the availability of these 
protection tracks. 

We propose the following extension to SDP: 



Session Level: 

Syntax: 

a=pnaine: <Chaimel_j)rofile_nam6/niin_bandwidth- inaxjbandwidtii> 

Explanation; 

^'pname**: indicates tiiat this attnbute is to define a channel profile, 
"channeljprofilejiame": dejBnes the name of this profile. 

"^ninjbandwidtfa - maxjbandwiddi: defines the bandwidth range (hat required for fiilly receiving 

all channels in this profile. 

Example: 

"a=pname:basic/56 - 1000" specifies tiiat there is a profile called 'i^asic" and its required 
bandwidth range is between ''56 - 1000'* kbps. 

Media Level: 

Syntax: 

a=profile:<profile_name/track_priority> 

Explanation: 

*^rofile": indicates that this attribute is to tell which channel profile this media belongs to. 
*^rofile_name**: specifies the profile name. 

**track_priority'*: specifies the priority level of this media (or track) in this particular profile. 
Example: 

''a'^^nofile: basic/1 " q)ecifies that this media appears in the channel profile named as "basic** with 
an assigned priority level of hi media level, there could be multiple "a=profile: ..." lines with 
different profile name under the same media. 

Syntax: 

a^protection: <tracldD==value> 

Explanation: 

'"protection": indicates ttiat dus media (or track) is protected by anodier track, such as a track 

contains FBC data of this media. 
*trackID»value": specifies the track control ID of the protection track, or the ID of the hintii^ 

track of the protection track. 

Example: 

^'a^^rotectiomtracklD^lZ", specifies that this media, under which this attribute line appears, is 
protected by a protection track fliat is hinted and fiie hinting track ID is ^12". 

With these extensions, a streaming server will be able to properly describe a layered streaming session to a 
client, and the client can selective subscribe to a group of channels defined by the channel profile it chooses 
&om the offered options. 




4. Channel Control Using RTSP 





The Ituidaiiiental advantage of layered video streaming is that video is transmitted tbrough multiple 
channels (or RTP channels). The more channels are used, the higher the network bandwidth consumed. The 
streaming system needs a mechanism to start and stop these channels dynanoacally depending on network 
conditions, such as available bandwidth. We have prototyped an adaptive streaming system, in which we 
extended the RTSP (RFC 2326) function for rate control The rate adaptation is achieved through channel 
subscription and un-subscription, in ttie following way: i 

9 When vidcQ layers and protection layers are loaded by the server, it associates each layer with an 
activity status variable. A layer's status could be either ACTIVE or INACTIVE. The server will only 
deliver layers that are in 'the ACTIVE status to the client 

• RTSP*s "SET PARAMETER" command is used by the client to set the active status variable of each 
layer in real-time. 

• The client estimates network conditions and decides when to start or stop a layer. 

This scheme is similar to die receiver-driven layered multicast [2] in the sense that in both schemes the 
receiving side actively performs the adaptation. The difference is that in our scheme the RTSP is used 
instead of IGMP to avoid long IGMP latencies that could affect the adaptation efficiency. However, for our 
scheme to si^ort nudticast and suppress the implosion of RTSP control message to a busy server, 
strategically located RTSP proxies in large scale networks to filter and merge RTSP control messages 
before they reach the server are necessary, which is beyond die scope of this contribution. 

The RTSP command used for channel control is illustrated in the following example: 

Cr^S: SET^PARAMETER rtsp://130.14a67.83/san^>le,mp4 RTSP/1 .0 
CSeq: 11 
Session: 3453643 
Content-length: 13 
Content-type: text/bool 

TrackJH: I // the 4th tiack is set to be 1 (ACTIVE) 

S-^C: RTSP/1 .0 200 OK 
CSeq: 1 1 

Date: 28 Jan 2002 15:32:10 GMT 

The protection layers (or tracks) are controlled in the same way as the video layers. Nevertheless, the client 
will engage different criteria to invoke or suppress the protection channels, depending on the loss 
characteristics and/or desired protection levels that can be determined by each client individually (based on 
e.g. employed buffer size, concealment strategy). 

The general procedures of layered streaming is illustrated in Figure 4 using FGS as an exainple. 
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Figure 4: General streaming procedures. 



5. On-demand Protection 

In most streaming systems, mainly two types of eiror-recovery methods are used: retransmission and 
forward-error-correction (or siiiq>ly FEC). The retransmission method has the advantage of high bandwidth 
utilization, but Uie disadvantage of long recovery delays that may not be tolerable for applications having 
strict delay constraints. The FEC method is the opposite of die retransmission. FEC can quickly do error- 
recovery, but involves an overhead of bandwidth consumption. 



In tiie past, there is' a distinct line between these two methods. An application design chooses eidier 
retransmission or FEC. However, the IP-based networks are heterogeneous and evolving. Applications 
could operate in completely different network environments, making the network conditions hard to 
predict This situation leaves application designs with difficulties for choosing the right error-recovery 
methods for all possible operating scenarios. 

An ideal solution for error-recovery would be that retransmission and FEC could be somehow combined 
togedier, and the application has the freedom to dynamically choose either of them or combine them in 
real-time according to its perceived network conditions. 

The hybrid ARQ and the adaptive FEC reported in [3] [4] are attractive solutions that combine the strengths 
of boA retransmission and FEC. In the hybrid ARQ, the video data are pre-encoded by some FEC coding 
scheme, such as Reed-Solomon (RS) codes, and then the sender and receiver use a specially designed 
ARQ-like protocol to perform the protection. 

In the adaptive FEC [4], FEC data are separated torn original media streams, and "joinTleave" 
commands are employed to achieve adaptive protection. This method has tiie following limitations: 

• It uses IGMP (Internet Group Management Protocol) to signal the join/leave action, which may 
introduce a very long latency in the signaling process that eventually defeat the protection purpose, 
such as retransmission. 

• It enqshases on the FEC coding algorithm but lacks an architecture and protocols to cany out the goals 
of adaptive FEC. 

The scheme described m this contribution goes beyond just the basic idea of adaptive FEC. It presents a 
realistic architecture and specifies the protocols that are needed for carrying out adaptive and efficient 
protection. With our scheme, applications are able to switch between different protection strategies 
dynamically. 
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Our enOTHrecovery mettiod can be inq>lemented as foUows. 

. A sepan-e protection track or tracks is/^ added r^^*-tg^^„ttTeSS J^y^S.^^ 
deems necessaiy. 

Figure 5 shows how protection tracks ace structured and stored in an MPEG-4 ffle. 

> 
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Figure 5: Proposed atiangement of protection tracks in an MPEG-4 file. 

T Tjj^„. s PTi and PT2 contain the FEC data of some video tracks. MTl and MT2 aUow these protection 
?aSL b;^TS i?Se^ ^fTand HT2 make these protection t«cks available to remote users 

throng streaming. 



The operation of this error-recovery method is schematically shown in Figure 6. 
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Figure 6: An illustration of the error-recoveiy scheme. 

In the example shown in Figure 6, channel RTPl - RTP3 carry the video data of different layers. RTP4 and 
5 cany the protection data. Both video channels and protection channels are controlled using RTSP in the 
same way, Ae client determines when it wants to turn on/off a particular channel. 



The RTSP command used for protection control is shown as the following. 



C-^: SET^PARAMETER rtsp://130.140.67.83/sample.n^ RTSP/1.0 
CSeq: 32 

Session: 3453643 

Content-length: 35 

Content-type: text/bool/integer 

Track_l 1:1 the 1 1 th track is set to be 1 (ACTIVE) 

range: 34521 - 34570 //50 packets are lequested 



S->C: RTSP/1 .0 200 OK 
CSeq: 32 

Date: 28 Jan 2002 15:33:10 GMT 



Explanation: 

Parameter range Syntax: 

range: start_seq_num - endjseq^num 

Implication: 

• as FEC: ^enend_seq_num»oo / 

• as Retransmission: when end_seqjium = start_seqjium + 1 

• as Hybrid: for other cases 



6. Conclusions 

The advantage of this framework for adaptive and efficient video streaming is highlighted below. 
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• It takes Ml advantage of the MPEG-4 file fonnal; and a general-purpose MPEG-4 server can perform 
adaptive protection to streaming applications. 

• Protection data are separated from protected data and changing the protection data can change tiie 
protection level or strategy, but the protection procedures remains the same. 

• With this method, applications can dynamically choose either retransmission-like protection or FEC- 
like protection, or hybrid ARQ, therefore, gaining better protection performance. 

• Using RTSP mstead of IGMP can achieve fester protection and provide more flexibUity to 
applications. 

• Tl^ streaming inethod is efficient for both unicast arid niulticast 

This contribution only outUnes an architecture framework for layered video streaming. We hope this work 
can bring up interesting discussions regarding layered video streaming in MPEG-4 community. Our 
prototyping work demonstrated that tiie multi-hinting method, RTSP channel control as well as Oie on- 
demand protection concepts briefly described in this contribution can effectively be used for Internet and 
m-home wireless transmission of video. Future work includes refining die syntax and semantics design of 
involved protocols and adaptation algorithms. 
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